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Abstract 


This document updates the IANA allocation rules and registry of IPv4 
and IPv6 Router Alert Option Values. 
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Les 


Introduction 


The IP Router Alert Option is defined for IPv4 in [RFC2113]. A 
Similar IPv6 option is defined in [RFC2711]. When one of these 
options is present in an IP datagram, it indicates that the contents 
of the datagram may be interesting to routers. The Router Alert 
Option (RAO) is used by protocols such as the Resource Reservation 
Protocol (RSVP) [RFC2205] and IGMP [RFC3376]. 


Both the IPv4 and IPv6 options contain a two-octet Value field to 
carry extra information. This information can be used, for example, 
by routers to determine whether or not the packet should be more 
closely examined by them. 


There can be up to 65536 values for the RAO. Yet, currently there is 
only a registry for IPv6 values. No registry or allocation policies 
are defined for IPv4. 


This document updates the IANA registry for managing IPv4 and IPv6 
Router Alert Option Values, and removes one existing IPv6 Router 


Alert Option Value. 


Use of the Router Alert Option Value Field 


One difference between the specifications for the IPv4 and IPv6 
Router Alert Options is the way values for the Value field are 
managed. In [RFC2113], the IPv4 Router Alert Option Value field has 
the value 0 assigned to "Router shall examine packet". All other 
values (1-65535) are reserved. Neither a management mechanism (e.g., 
an IANA registry) nor an allocation policy are provided for the IPv4 
RAO values. 


The IPv6 Router Alert Option has an IANA-managed registry 
[IANA-IPv6RAO] containing allocations for the Value field. 


In [RFC3175], the IPv4 Router Alert Option Value is described as a 
parameter that provides "additional information" to the router in 
making its interception decision, rather than as a registry managed 
by IANA. As such, this aggregation mechanism makes use of the Value 


field to carry the reservation aggregation level. For the IPv6 
option, IANA has assigned a set of 32 values to indicate reservation 
levels. However, since other registrations have already been made in 


that registry, these values are from 3-35 (which is actually a set of 
33 values). 


Although it might have been desirable to have the same values used in 
both the IPv4 and IPv6 registries, the initial allocations in 
[RFC2711] and the aggregation-level allocations in [RFC3175] have 
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made this impossible. The following table shows the allocations in 
the IPv6 registry and the values used in the IPv4 registry, where the 
latter have been deduced from [RFC2113] and [RFC3175] with the 
assumption that the number of aggregation levels can be limited to 32 
as in the IPv6 case. Entries for values 6 to 31 have been elided for 


brevity. 

+---------- +------------------------- +------------------------------ + 

| Value | IPv4 RAO Meaning | IPv6 RAO Meaning 

tH ss-SSSse5 tae Sete sSS Shee SSeS eet Poe See See Se eee SS SSeS + 

| o | Router shall examine | Datagram contains a 

| | packet [RFC2113] | Multicast Listener Discovery | 

| | [RFC2205] [RFC3376] | message [RFC2711] [RFC2710] | 

| | [RFC4286] | [RFC4286] | 

| 1 | Aggregated Reservation | Datagram contains RSVP | 

| | Nesting Level 1 | message [RFC2711] [RFC2205] 

[RFC3175] 

| 2 | Aggregated Reservation | Datagram contains an Active | 

| | Nesting Level 2 | Networks message [RFC2711] 

| | [RFC3175] | [Schwartz2000] | 

| 3 | Aggregated Reservation | Aggregated Reservation | 

| | Nesting Level 3 | Nesting Level 0 [RFC3175] (*) | 

RFC3175] 

| 4 | Aggregated Reservation | Aggregated Reservation | 

| | Nesting Level 4 | Nesting Level 1 [RFC3175] | 

| | [RFC3175] | | 

| 5 | Aggregated Reservation | Aggregated Reservation | 

| | Nesting Level 5 | Nesting Level 2 [RFC3175] | 

| | [RFC3175] | | 

| 32 | Aggregated Reservation | Aggregated Reservation | 

| | Nesting Level 32 | Nesting Level 29 [RFC3175] 

| | [RFC3175] | | 
33 Reserved Aggregated Reservation 

| | | Nesting Level 30 [RFC3175] 

| 34 | Reserved | Aggregated Reservation 

| | | Nesting Level 31 [RFC3175] | 

| 35 | Reserved | Aggregated Reservation 

| | | Nesting Level 32(*) | 

| | [RFC3175] | 
36-65534 Reserved Reserved to IANA for future 

| | | assignment | 

| 65535 | Reserved | Reserved [IANA-IPv6RAO] 

+---------- +------------------------- +—------------------------------ + 


Note (*): The entry in the above table for the IPv6 RAO Value of 35 
(Aggregated Reservation Nesting Level 32) has been marked due to an 
inconsistency in the text of [RFC3175], and is consequently reflected 
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in the IANA registry. In that document, the values 3-35 (i.e., 33 
values) are defined for nesting levels 0-31 (i.e., 32 levels). 
Similarly, value 3 is a duplicate, because aggregation level 0 means 
end-to-end signaling, and this already has an IPv6 RAO value "1" 
assigned. 


Also note that nesting levels begin at 1 for IPv4 (described in 
Section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in Section 6 of 
[RFC3175]). 


Section 3.2 of this document redefines these so that for IPv6, value 
3 is no longer used and values 4-35 represent levels 1-32. This 
removes the above inconsistencies. 


3. IANA Considerations 


This section contains the new procedures for managing IPv4 Router 
Alert Option Values. IANA has created a registry for IPv4 Router 
Alert Option Values (described in Section 3.1) and has updated the 
IPv6 Router Alert Option Values (described in Section 3.2). 


IP Router Alert Option Values are currently managed separately for 
IPv4 and IPv6. This document does not change this, as there is 
little value in forcing the two registries to be aligned. 


3.1. IANA Considerations for IPv4 Router Alert Option Values 
The Value field, as specified in [RFC2113], is two octets in length. 


The Value field is registered and maintained by IANA. The initial 
contents of this registry are: 


+-——------------ tan E EE EAT E ENS t----------- + 
| Value | Description | Reference | 
+-------------— E = E + 
| o | Router shall examine packet | [RFC2113] | 
| 1-32 | Aggregated Reservation Nesting Level | [RFC3175] | 
| 33-65502 | Available for assignment by the IANA | | 
| 65503-65534 | Available for experimental use | 

| 65535 | Reserved | 

r == r = Pe Son + 


New values are to be assigned via IETF Review as defined in 
[RFC5226]. 
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3.2. IANA Considerations for IPv6é Router Alert Option Values 


The registry for IPv6é Router Alert Option Values continues to be 
maintained as specified in [RFC2711]. In addition, the following 
value has been removed from the IANA registry and reserved for 
possible future use (not to be allocated currently). The reason is 
that it is a duplicate value; aggregation level 0 means end-to-end 
Signaling, and this already has an IPv6 RAO value "1" assigned. 


prisin aA þe + 
| Value | Description | Reference | 
Feee ena E E A EEE + 
| 3 | RSVP Aggregation level 0 | [RFC3175] | 
paronan pHo eih E + 


A A ER 4------------------ e + 

| Value | Description | Reference | 

4------------- A A t----------- + 

| 65503-65534 | Experimental use | | 

Tennes an E ES EPE AS + 
4. Security Considerations 


Since this document is only concerned with the IANA management of the 
IPv4 and IPv6 Router Alert Option Values registry, it raises no new 
security issues beyond those identified in [RFC2113] and [RFC2711]. 


Yet, as discussed in RFC 4727 [RFC4727], production networks do not 
necessarily support the use of experimental code points in IP option 
headers. The network scope of support for experimental values should 
be evaluated carefully before deploying any experimental RAO value 
across extended network domains, such as the public Internet. The 
potential to disrupt the stable operation of the network hosting the 
experiment through the use of unsupported experimental code points is 
a serious consideration when planning an experiment using such code 
points. 


When experimental RAO values are deployed within an administratively 
self-contained network domain, the network administrators should 
ensure that each value is used consistently to avoid interference 
between experiments. When experimental values are used in traffic 
that crosses multiple administrative domains, the experimenters 
should assume that there is a risk that the same values will be used 
simultaneously by other experiments, and thus that there is a 
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possibility that the experiments will interfere. Particular 
attention should be given to security threats that such interference 


might create. 
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